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Abstract. In agile ontology-based software engineering projects sup¬ 
port for modular reuse of ontologies from large existing remote reposito¬ 
ries, ontology project life cycle management, and transitive dependency 
management are important needs. The contribution of this paper is a new 
design artifact called OntoMaven combined with a unified approach to 
ontology modularization, aspect-oriented ontology development, which 
was inspired by aspect-oriented programming. OntoMaven adopts the 
Apache Maven-based development methodology and adapts its concepts 
to knowledge engineering for Maven-based ontology development and 
management of ontology artifacts in distributed ontology repositories. 
The combination with aspect-oriented ontology development allows for 
fine-grained, declarative configuration of ontology modules. 


1 Introduction 

Sharing and reusing knowledge in ontology-based applications is one of the main 
aims in the Semantic Web as well as the Pragmatic Wetj^[T3l[8l|9], which requires 
the support of distributed ontology management, documentation, validation and 
testing. Typically ontologies are developed and maintained in an iterative and 
distributed way, which requires the support of versioning [6l |T0] and modu¬ 
larization mm- Aspect-Oriented Ontology Development (AOOD) [TTJ [12] en¬ 
ables weaving of cross-cutting knowledge concerns into the main ontology model, 
which requires meta-level descriptions of ontology aspects and management of 
distributed knowledge models. 

In this paper we introduce OntoMaverQ which adapts a highly successful 
method and tool in distributed software engineering, namely Apache Maverj^ 
for the Maven-based management of distributed ontology repositories. The On¬ 
toMaven approach supports ontology engineering in the following ways: 

- OntoMaven remote repositories enable distributed publication of ontologies 
as ontology development artifacts on the Web, including their metadata 

^ http://www.prasmaticweb.info 
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information about life cycle management, versioning, authorship, provenance, 
licensing, knowledge aspects, dependencies, etc. 

- OntoMaven local repositories enable the reuse of existing ontology artifacts in 
the users’ local ontology development projects. 

- OntoMaven’s support for the different development phases from the design, de¬ 
velopment to testing, deployment and maintenance provides a flexible life cycle 
management enabling iterative agile ontology development methods, such as 
COLM 1^ with support for collaborative development by, e.g., OntoMaven’s 
dependency management, version management, documentation and testing 
functionalities, etc. 

- The extension of OntoMaven with aspect-oriented concepts allows the declar¬ 
ative configuration and automated interweaving of ontology modules during 
the build phase. 

- OntoMaven plug-ins provide a flexible and light-weight way to extended the 
OntoMaven tool with existing functionalities and tools, such as semantic ver¬ 
sion management (e.g., SVont - Subversion for Ontologies [iiini) , semantic 
documentation (e.g., SpecGen Concept Grouping [2]), dependency manage¬ 
ment of aspect-oriented ontology artifacts (e.g. m), automated testing (e.g., 
with the W3C OWL test cases and external reasoners such as Pellet), etc. 

- Maven’s API allows easy integration of OntoMaven into other ontology engi¬ 
neering tools and their integrated development environments (IDE). 

The further paper is structured as follows: Section describes the concep¬ 
tual design of OntoMaven based on Maven’s remote and local repositories, the 
Project Object Model (POM), and plug-ins. Sectionintroduces the approach 
to aspect-oriented ontology development. Section proves the feasibility of the 
proposed concepts with a proof-of-concept implementation of the OntoMaven 
design artifact. Section compares the OntoMaven functionalities to the tool 
support of the major existing ontology engineering tools. Finally, sectionsum¬ 
marizes the current OntoMaven work and discusses future research. 


2 OntoMaven’s Design and Concept 

In the following subsections we adapt the main concepts of Maven, so that they 
can be used in ontology development and ontology life cycle management. In 
particular, we focus on the (distributed) management of knowledge artifacts 
(ontologies / ontology modules) and their versioning, import and dependency 
management, module configuration, documentation, and testing. 


2.1 Management and Versioning of Ontology Artifacts 

Typically, in ontology reuse there is a need for versioning and life cycle man¬ 
agement. Gombinations with existing ontologies (by ontology matchmaking and 

^ http://www.corporate-semantic-web.de/colm.html 
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alignment) might lead to transitive dependencies which need to be described and 
managed. OntoMaven therefore adopts Maven’s artifact concept. It describes 
and manages ontologies as ontology artifacts in a Maven Project Object Model 
(POM). The typical steps to add an ontology (module) as an OntoMaven artifact 
to a POM are: 

1. Find ontology module(s) 

2. Select the right module and version 

3. Analyse and resolve dependencies of the modules 

4. Declaratively describe the ontology artifact in a POM 

Many ontology languages support imports or integration of distributed on¬ 
tologies. For instance, the W3C Web Ontology Language (OWL) therefore has a 
specialized owl: import statement. Typical recurring tasks which are automated 
by OntoMaven in such modular import and reuse scenarios are, 

- check the existence of the imported ontology (module) referenced by the 
defined URI in the import statement (and find alternative URLs from pre¬ 
configured repositories if the ontology does is not found at the import URI). 

- management of ontologies / ontology modules as ontology artifacts in Maven 
repositories including their metadata descriptions such as versioning informa¬ 
tion. 

- download of ontology artifacts from remote repositories (including transitive 
imports) to a local development repository in order to support offline devel¬ 
opment of ontologies 

Another important aspect in the agile and collaborative development of on¬ 
tologies is the support for version management. Typical requirements are main¬ 
taining consistency and integrity, as well as provenance data management (e.g. 
authorship information) throughout the version history. The approach in On¬ 
toMaven is based on the ontology versioning tool SVont, which is an extension 
of the version management tool Subversion. 


2.2 Documentation 

Documentations of ontologies ease maintenance and reuse. The typical distinc¬ 
tion is into user documentation and technical documentation. While the former 
supports the users of an ontology, e.g. in their task to populate the ontology with 
instance data, the latter, technical documentation, supports the ontology devel¬ 
oper. Ontology concept groupings and summarizations of concepts provides the 
documentation reader with an easier way to understand the ontology vocabu¬ 
lary. m Maven supports the documentation phase and provides goals for creating 
and publishing automated reports. In OntoMave we make use the SpecGen ex- 
tensiorj^ for automated concept grouping, in order to create the technical and 
user documentation in an OntoMaven plugin which is executed by the mvn site 
command. 
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2.3 Testing 

Testing is an important phase in the ontology life cycle. In particular, in agile 
iterative development processes testing allows detecting inconsistencies, anoma¬ 
lies, improper design, as well as validation against, e.g., the intended results of 
domain experts’ competency questions which are represented as ontology test 
cases. Maven supports a testing phase in which automated tests are executed 
and the results are reported by the Maven command mvn test. As standard 
test types OntoMaven by default supports the W3C OWL test case^ syntax 
checker^ consistency checker^ and entailment test. The produced test results are 
compliant to the W3C recommendation and the created test reports show if the 
ontology model is consistent, inconsistent or if the result is unknown. Further 
test types can be implemented as Maven plug-ins and added to the OntoMaven 
projects test suites by the user. 


3 Aspect-Oriented Ontologies 

Aspect-oriented design and programming are paradigms in software develop¬ 
ment and are means for system modularization by separation of cross-cutting 
concerns. In software systems, typical cross-cutting concerns comprise logging, 
authentication, and transaction management. In [12], we proposed the idea of 
aspect-oriented ontologies, providing an approach to ontology modularization 
based on cross-cutting concerns. 

As in software development, cross-cutting concerns are linked to require¬ 
ments. Requirements can be functional, i.e., directly related to the business 
goals the system or ontology is supposed to accomplish. Non-functional require¬ 
ments, in contrast, are related to goals concerning the system or ontology itself. 
Functional ontology requirements are generally directly related to the compe¬ 
tency questions the ontology is supposed to answer, while examples for non¬ 
functional requirements include provenance information, multilinguality and rea¬ 
soning complexity. 

Each of these requirements is mapped to one ore multiple sets of axioms in an 
ontology. If there exists a relationship between an aspect and an axiom, it means 
that this axioms belongs to the aspect in question. This way, an ontology can 
be modularized into (possibly overlapping) modules, each module representing a 
requirement, and each module-requirement pair being encapsulated in an aspect. 

Aspects can, in turn, be formal descriptions themselves, i.e., just as the ontol¬ 
ogy module they are mapped to, they can be ontological statements as well. For 
example, a set of facts in an OWL ontology can be related to a temporal aspect 
(e.g. Bonn is capital of West Germany^ which was only valid from 1949 to 1990), 
where the temporal aspect is an OWL individual that comes with relations and 
properties formalized using the W3C time ontology and representing the time 
interval 1949-1990. 


http://www.w3.org/TR/owl-test/ 
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The individual representing the aspect may be directly referenced by its 
IRI (if it is a named individual). Beyond that, it is possible to define super 
aspects by using some sort of query (e.g. all the things that happened during the 
20th eentury which is equivalent to all facts in the ontology that are related to 
temporal aspects which are valid between 1900 and 1999). 

The left part of Figure depicts the process of enriching an ontology with 
aspects. 



Ontology with Ontology module selection 

aspect annotations as an OntoMaven goal 


Fig. 1. Depiction of the ontology aspect configuration plugin for OntoMaven (dashed 
box on the right). One or several aspect names are passed to the OntoMaven plugin 
as arguments. The result is an ontology module including exactly those axioms that 
belong to the given aspects. Axioms of the original ontology (left) have been annotated 
with entities from an external aspect ontology (center). Axiom declaration is based on 
queries or is performed manually. 


When the ontology is deployed in the context of an application, modules 
can be recombined by directly referencing their URIs or by using queries as 
described above. This may happen either dynamically at runtime or during the 
configuration phase of the application in a descriptive manner. 

In the following section, we describe how aspect composition has been im¬ 
plemented as a configuration step in the application and ontology management 
lifecycle of OntoMaven. 


4 Proof-of-Concept Implementation - OntoMaven Plugins 

The implementation of OntoMaven [4] extends and adapts Maven, so that it 
supports the management of ontology modules in Maven repositories. This sec¬ 
tion describes how the OntoMaven approach, using Maven repositories and the 
Maven plug-in extension mechanism. A Maven plug-in is a collection of one or 
more goals. The implementation of a Maven plug-in is done in an Maven Plane 
Old Java Objeet (MOJO). In the OntoMaven approach, the phases and goals, 
which the plug-in implements, are defined by JavaDoc annotations in the source 
code of the Mojo class. For instance, the following annotations define that the 
implemented plug-in is used in the phase test and that is has a goal called 
test-syntax: 
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©phase test //plug-in used in test phase 

©goal test-syntax // goal with the name "test-syntax" 


Parameters are used to configure the plug-in execution. For instance, the 
following code snippet defines a required parameter compliancemode with the 
default value strict: 

♦©parameter expression = compliancemode ©default-value="strict" ©required 


Such plug-in parameters can be configured in a POM.xml file or directly 
when calling a goal, e.g. mvn . . . -Dcompliancemode=strict. An implemented 
plug-in can be installed using Maven mvn install and the plug-in goals can be 
integrated into the POM.xml of an OntoMaven project, as the following example 
listing shows for the plug-in SVontPlugin and the goal semantic-diff: 

<build> 

<plugins> <plugin> 

<groupId>de.csw.ontomaven</groupId> 

<artif actId>SVontPlugin</artif actId> 

<version>l.O-SNAPSHOT </version> 

<executions> <execution> 

<goals> <goal>semantic-diff</goal> 


The following subsections provide further details about the proof-of-concept 
implementations of the main plug-ins in OntoMaven. We first describe the On¬ 
toMaven repositories which are the persistence and back-end layer for storing 
and managing ontologies. 


4.1 OntoMaven Repositories 

OntoMaven can use all Maven compliant repositories. One of the strengths of 
Maven is that is uses a folder structure following a standard folder layout for its 
repositories. For the OntoMaven proof-of-concept implementation we adapted 
the Apache Archiva Build Artifact Repository Manageij^ as a managing tool 
providing a user interface for the OntoMaven repositories. The left figureshows 
the upload user interface. 

Via this form an ontology can be uploaded to an OntoMaven repository 
together with its POM file. The artifact’s metadata contains information about 
the group id, artifact id, version, packaging and optional additional classifier 
information. The POM provides all necessary information about the artifact 
and its dependencies. In OntoMaven these dependencies are used to describe 
(transitive) imports from an ontology, which are resolved by the OntoMvnImport 
plug-in (see subsection |4.2| ). 

The right figure gives an example of the Archiva user interface showing the 
management information of an ontology artifact called Camera OWL Ontology. 
Under the interface menu link Dependencies the dependencies of this ontology 
can be found. 
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Camera OWL Ontology 

Info Dependencies Used By Mailing Lists 


(33 Upload Artifact 

CSroup Id*: 

Artifact Id*: \ 

\rersion*: 


rtoDl / xfront / com / ontologies 1 Camera OWL Ontology 

It Is an example for an ontology In owl 

Repository snapshots 

Group ID xfront.com.ontologles 

Artifact ID Camera OWL Ontology 

Version 1.0-20121209.221136-1 

Packaging owl 

Other Versions 1.0-20121709.2211.36-1 

1 

J 

POM Snippet 

Packaging*: p 

1 

<groupId>xf rone. ciimi. oncalogLes</groupId> 

Classifier: p 

J 

<ver3lQn>1.0-SNAPSHOT</ver3iQn> 

n Generate Maven 2 POM 

Artifact File*: \ | Durchsuchen_ | 


</de^dency> " 

POM File: I I Durchsuchen. I 

Repository Id: Q internal | 1 


URL httD://examDle.orQ 

Organisation CameraOwl 


Submit 

License Common Public License Version 1.0 



Fig. 2. Archiva User Interface - Ontology Artifact Upload and Management 


Once managed in an online OntoMaven repository, an ontology artifact can 
be used in any OntoMaven ontology development project. The following listing 
gives an example how a remote repository can be configured and a dependency 
to an ontology artifact (here the Camera-OWL-Ontology) can be defined in the 
POM.xml document of a project. 

<profiles> <profile> 

<id>2</id> 

<activation> <activeByDefault>true</activeByDefault> </activation> 

<repositories> <repository> 

<snapshots> <enabled>true</enabled> </snapshots> 

<id>snapshots</id> 

<name>OntoMaven Snapshot Repository</name> 

<url>\protect\vrule widthOpt\protect\href{http://www.corporate-semantic-web.de/repository/snapshots/</url}-{ht 

</profiles> 

<dependencies> <dependency> 

<groupId>xfront.com.owl.ontologies</groupId> 

<artifactId>Camera-OWL-Ontology</artifactId> 

<version>l.0-SNAPSH0T</version> <type>owl</type> 

</dependency> </dependencies> 


4.2 OntoMvnImport 

This plug-in implements the imports of ontologies into the Maven repositories. 
It also checks if the import statements in the ontology (including transitive im¬ 
ports) can be resolved. Therefore, it maintains an updated list of referenced 
URIs to the ontology resources loaded to the repository. This list follows the 
OASIS XMLCatalog standard which also specifies a technique for the auto¬ 
mated replacement of external references in XML documents. In OntoMaven 
we use this automated replacement technology to replace the URI references to 
imported external ontologies with references to the internal ontology arti¬ 
facts, which are locally managed in an OntoMaven repository. This replacement 
approach avoids the continuous import and use of external ontologies during an 
OntoMaven development project. After the first loading of an ontology as repos¬ 
itory artifact by the OntoMvnImport plug-in, the plug-in always checks if there 
is an ontology artifact listed in the XMLCatalog. If there is an existing reference 
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to an ontology artifact, it will use it instead of any externally referenced ontol¬ 
ogy. The following listing shows how the plug-in can be used in a OntoMaven 
POM. In the configuration it defines the input ontology and sets the local 
parameter to true, indicating that the ontology should be loaded to the local 
repository and that the local version of the ontology should be used. 

<build> <plugins> <plugin> 

<groupId>de.csw.ontomaven</groupId> 

<artif actId>0ntoMvnImport</artifactId> 

<version>l.0-SNAPSH0T</version> 

<configuration> 

<owlfile>src/resource/reputation.owl</owlfile> <local>true</local> 

</configuration> 

<executions> <execution> 

<goals> <goal>owlimport</goal> </goals> 


4.3 OntoMvnApplyAspects 

This plug-in contributes to the package goal of Maven’s build lifecycle. It takes 
the ontologies that are part of the OntoMaven project and selects exactly those 
modules that are specified by the Maven parameter userAspects. An additional 
parameter aspectsIRI allows to specify a custom OWL object or annotation 
property which is used to map the aspects to the ontology modules. The param¬ 
eter if IncludeOriginalAxioms specifies whether those axioms in the ontology 
that are free of aspects (the base module) should be included in the resulting 
ontology or not. This allows to either configure an ontology and enable selected 
aspects of it or to merely extract a module on its own and use it in the applica¬ 
tion. An example configuration is shown in the following POM listing: 

<build> <plugins> <plugin> 

<groupId>de.csw.ontomaven</groupId> 

<artif actId>0ntoMvnApplyAspect s</artif actId> 

<version>l.0-SNAPSH0T</version> 

<configuration> 

<userAspects> 

<aspect>\protect\vrule widthOpt\protect\href{http://example.org/reputation#Reputationl23</aspect}{http://example. 
<aspect>\protect\vrule widthOpt\protect\href{http://example.org/provenance#prov_789</aspect}{http://example.org/p 
</userAspects> 

<aspectsIRI>\protect\vrule widthOpt\protect\href{http://corporate-semantic-web.de/aspectOWL#hasAspect</aspectsIRI}-{ht 
<includeOriginalAxioms>true</includeOriginalAxioms> 

</configuration> 


4.4 Other Plug-Ins 

The OntoMvnSvn and OntoMvnGit plug-ins provide ontology versioning support 
for OntoMaven. They use extensions to Subversion and Git, respectively. The 
Subversion extension is called SVonl|^ [6], which can compute semantic differ¬ 
ence^ for the versioning of ontologies. SVont supports typical Subversion com¬ 
mands such as checkout, status, diff, commit, and info. 

The implementation of the commands status and diff and the plug-in 
OntoMvnReport are described in more detail in [3. 


http://www.corporate-semantic-web.de/svont.html 
^ for the decription logic EL 
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Fig. 3. OntoMaven Summary and Report Views 


The ontology report summary is created by the goal ontologyreport. The 
middle figure shows an example ontology summarization which gives an 
overview about the general description, the format, the semantic profile, im¬ 
ported ontologies and a summary about the ontology’s statistics (number of 
classes, datatype properties, object properties, etc.). 

For the documentation of the ontology, the plug-in uses existing automated 
ontology documentation tools. We have integrated the SpecGen ontology doc¬ 
umentation tool which creates a HTML page containing detailed information 
about the classes and the properties. We further extended SpecGen with various 
algorithms for creating structure based concept groupings. HE] These group¬ 
ings are used as basis for a visual documentation of the ontology. To support 
this process of creating such concept groups for the documentation of ontologies 
we extended the SpecGen tool with an automatic concept grouping functionality 
and embedded it for the OntoMaven documentation. 

More detailed reports in the form of technical ontology report and network 
visualizations may be created by the goals technicalreport and visualizer, 
respecively (see right side of Figure]^. The latter uses different graph visualiza¬ 
tions E3 


4.5 OntoMvnTest 

The OntoMvnTest plug-in implements functionalities for the test phase. The 
plug-in executes the configured tests using the goal test. It is also used internally 
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in other phases such as the package goal. The plug-in implementation uses 
the Pellet reasoneij^to execute the ontology test cases. As default test suites 
the plug-in supports the W3C OWL Test Cases. This test collection contains 
different types of test cases, such as a test that determines and returns the OWL 
sublanguage, tests for inconsistency checks, and entailment tests, which test if 
the intended conclusions (represented by an output ontology) are entailed in the 
input ontology model. For instance, the intended entailment test result values 
are Entailment (positive test result) or NoEntailment (negative test result). 


5 Related Work Evaluation 


There are many existing ontology engineering methodologies and ontology edi¬ 
tors available. The focus of e.g. Protegj^ Swoopj^ and Top Braid Composeif^ 
is in the front-end providing user interfaces for ontology modeling / represen¬ 
tation. Other editors support, e.g., visual ontology modeling such as Thematix 
Visual Ontology Modeler (VOM)p^ which enables UML-based ontology mod¬ 
eling based on the OMG Ontology Definition Metamodel (OMG ODIV^^, or 
lightweight domain specific vocabulary development, such as Leon^^ [10]. On- 
toMaven mainly differs from them in the Maven-based approach how it man¬ 
ages and declaratively describes the development phases, goals, and artifacts in 
a Maven Project Object Model (POM). In particular, OntoMaven has a focus 
on managing and (re-) using existing distributed ontologies in the implementa¬ 
tion of ontology-based applications, while the editors have a focus on supporting 
the modelling of ontologies for later use. That is, OntoMaven is not a full on¬ 
tology modeling tool as e.g.. Protege, Swoop, and Top Braid Gomposer, which 
provide a development user interface. Instead OntoMaven’s has its strength in 
the back-end management of distributed ontology modules including support for 
reuse (transitive imports), dependency management and collaboration (semantic 
versioning). Further implementation-specific and plug-in-specific differences are 
in the underlying details of the provided functionalities of OntoMaven such as 
POM-based dependency management, semantic versioning, semantic documen¬ 
tation etc. For a comparison see Table 

The W3G Wiki lists several existing ontology repositoriej^ Further ontol¬ 
ogy repositories are, e.g., COLORhp^for ontologies written in the ISO Common 
Logic (CL) ontology languages and Ontohulp^ which maintains a set of heteroge¬ 
nous ontologies. The current focus of these projects is on collecting and listing of 
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Table 1. Functional Comparison of OntoMaven with Ontology Development Tools 



OntoMaven 

Protege 

Swoop 

Top Braid Composer 

Repositories 

yes (local and remote) 

yes (local and remote) 

no 

yes (by Allegro Graph 4 
Plugin) 

Reuse (Import) 

yes (dependency man¬ 
agement) 

yes 

yes 

yes 

Collaboration 

(Versioning) 

yes (semantic diff) 

no 

no 

no 

Documentation 

yes (text and visual) 

yes (text and visual) 

yes (only text) 

yes (text and visual in 
Maestro version) 

Testing 

yes 

yes 

yes 

yes 

Extensibility 

yes 

yes (many existing plug¬ 
ins) 

yes 

yes (commercial) 


existing ontologies. Apart from simple search functionalities there is no support 
for repository-based ontology development which is the focus of OntoMaven and 
OntoMaven repositories. 

New standardization efforts such as OMG Application Programming Inter¬ 
faces for Knowledge Bases (OMG APMKB^^aim at the accessability and inter¬ 
operability of heterogenous ontologies via standardized programming interfaces. 
OntoMaven can act as one possible implementation of the development support 
functionalities of OMG’s API4KB. With its Maven-based approach for structur¬ 
ing the development phases into different goals providing different functionali¬ 
ties during the software development project’s life cycle, OntoMaven supports 
in particular agile ontology development methods, such as GOLM [5], as well 
as development methods which are inherently based on modularization such as 
aspect-oriented ontology development m- 


6 Conclusion 

Apache Maven is a widespread and highly successful tool in Software Engi¬ 
neering for build automation and development project life cycle management. 
The contribution in this paper is a new design artifact called OntoMaven which 
adapts Maven for ontology-based development and dynamic configuration and 
use of ontology modules by the means of Aspect-oriented ontologies (AOOD). 
It is built using Maven’s plugin-based architecture. The proof-of-concept of On¬ 
toMaven implements several useful plugins which interface with existing ontol¬ 
ogy development tools and functionalities such as the plug-ins OntoMvnlmport^ 
OntoMvnApplyAspects^ OntoMvnSVN, OntoMvnReport^ and OntoMvnTest. 
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